Improve cmake#100
Conversation
|
To the best of my knowledge, the main reason is that this is the conventional layout for libraries intended to be consumed by other projects. Instead of exposing headers directly, it is generally recommended to organize them so that consumers can include them like this: #include <project_name/header_name.h>This helps avoid collisions if multiple libraries happen to provide a header with the same name. A generic: #include <minmea.h>is more likely to conflict than: #include <minmea/minmea.h>This convention also works well with package managers like vcpkg and CMake's I first came across this recommendation in the first edition of Modern CMake for C++ by Rafał Świdziński. On page 96, it suggests structuring a library like this: When the #include <lib3/public.h>rather than: #include <public.h>So I think moving That said, I don't think this is strictly required if the project is intentionally kept as a single-header library; it is more about making the library easier to consume as it grows. |
|
Also dear @kosma will appreciate it if you take a look at the pull request in vcpkg for this library: microsoft/vcpkg#52281 (comment) The following is a minimal example that fetches minmea from vcpkg: CMakeLists.txt You can put all these in an empty directory and run: Just make sure vcpkg is installed in ~/.vcpkg instead of ~/vcpkg. That's where my CMakePresets.json expect it to be. |
Here is a clean, modern, FetchContent-friendly CMake rewrite of the project. It is structured so that:
FetchContentinstall()+find_package()How users consume it (FetchContent)
Or with find_package (after install)
What is improved vs original
✔ Fully target-based
No global
CMAKE_C_FLAGS✔ Safe for embedding
Works inside other projects without side effects
✔ FetchContent compatible
No assumptions about install step
✔ Proper namespace
minmea::minmea✔ Clean install/export system
Supports
find_package✔ Optional components
✔ Modern CMake practices